“Rule engines” are typically self-contained applications that include a number of state variables, a number of actions to perform, and a number of “rules” that are used to determine when to perform a particular action. A typical rule includes a logical equation formed using the variables, such that a specified action is performed when the logic equation evaluates to true. When this occurs, the rule is said to “fire,” and the specified action is performed. The logic equations that are evaluated for a rule are sometimes called “predicates”; a rule will only fire when its predicates evaluate to true. A simple example of a rule for turning on a light might be:IF (TIME>DUSK) THEN (turn_on_light)
According to this example, when a state variable TIME becomes greater than a DUSK value, a “turn_on_light” action is triggered.
Rule engines access a collection of various rules, and typical rule engine implementations employ pattern matching techniques to determine which rules to fire. Ordinarily, the rules are organized in a flat structure; a number of individual rules are defined, each with its own individual predicate. In order to create more complex rule schemes, individual rules may be “linked” together as “chains,” thus allowing a series of actions to be performed in succession in response to an event. Linkage between individual rules is typically achieved by state variables: when an event causes a first rule to fire, a state variable is set that will result in the firing of a second rule, and so forth until all the desired actions have been completed.
FIG. 1 illustrates an example of a collection of individual rules to be executed by a prior art rule engine 100 in response to an Event 101. When Event 101 occurs, the rule engine 100 applies its pattern matching techniques and fires Rule 102, which has Event 101 as its predicate. Action 110 is performed, and a state variable 122 is set. When action 110 has been completed, control is passed back to the rule engine 100, which then applies its pattern matching techniques again to determine whether any further rules should be fired. Since Rule 104 includes a predicate containing the state variable 122, the rule engine 100 fires Rule 104. Action 112 is performed, and control is passed back to rule engine 100. This approach requires the use of variables to create complex rule functionality, and to specify a firing order for rule actions.
Rule engines have been found to be useful in conjunction with home automation systems, where rules are composed to perform various activities directed to household operations (e.g., turning on a light, unlocking a door, etc.). Currently, several companies in the home automation field are providing home automation systems with built-in rule engines, including X-10's “ActiveHome,” IBM's “Home Director,” Home Automated Living's “HAL2000,” and products by Savoy Automation and Integrated Media Systems, to name a few. A problem with such embedded rule engines (in addition to the problems described previously), is that they are less open in their architecture, as they are typically tightly coupled to the particular vendor's application and system design. For example, at a lower level, the state variables and particular actions to perform will vary from application to application, and at a higher level, the rule syntax, transmission protocols, and rule evaluation process can vary from vendor to vendor. This tight coupling between rule engines and the applications in which they are embedded (and the proprietary nature of each implementation) tends to motivate vendors to ignore each other's rule engine implementations and create their own. Thus each rule engine has different user interfacing requirements and different rule processing functionality.
Another problem with the use of tightly coupled rule engines with home automation applications is that they are limited in the addition of new features, enhancements or equipment. If the user desires additional functionality not supported, he must either wait for the vendor to implement such functionality in its proprietary rule engine (via an add-on or upgrade), or use a separate application having its own rule engine and associated browser/editor. This unnecessarily increases complexity and difficulty of use for the user, as the user must keep track of the policies and rules indigenous to each application, keep track of the various rules implemented across each application, and deal with each application's user interface (browser). It also prevents the user from constructing rules that combine the functionality of each separate application.
A further problem of tightly coupled rule engines is the possibility for system crashes or hangs due to software or hardware malfunctions. For example, if the software that implements a rule encounters an error condition, the rule action processing can hang the rule engine, and prevent further processing of other rules by the rule engine. While these problems can be minimized by building protections into the application, these protections add further complexity to the application.